In networking, quality-of-service (QoS) systems may be used to specify the precedence of competing packet flows. In some cases these flows may be a simple connection between a sender and a receiver. In other cases these flows may be a connection between a sender and receiver that passes through one or more proxies, some or all of which may be transparent to the sender and receiver. Standardized QoS signaling mechanisms exist, such the TOS (“Type of Service,” RFC 1349) and later the DSCP (“Differentiated Services Codepoint,” RFC 2474, RFC 2475) bits in the IP header. However, these may not be deployed across networks in a consistent way, however, and their presence or characteristics cannot be relied upon except when the same administrator controls the entire network. When data traverses networks owned by a third party, which is may be the case in wide-area networks (and especially the Internet), in some cases only the most basic IP functionality can be assumed, and that the bottleneck gateway will ignore any QoS bits in the packets.
QoS is often implemented at a bandwidth bottlenecks. These bottlenecks sometimes occur at a fast-to-slow transitions in network speed, for example at a device bridging a LAN and a WAN. If there is a backlog of packets from different flows at a device, the device can make a decision using QoS about which flow should have a packet sent next. In traditional QoS, equalizing bandwidth between connections may be accomplished with fair queuing, provided that other circumstances (such as excessive losses) do not prevent a connection from achieving its fair bandwidth share. In some implementations of fair queuing, each connection has its own queue. When the total amount of queuing becomes excessive, a packet is dropped from the connection with the longest queue. Because of the nature of fair queuing (which outputs packets on a round-robin basis), the connection with the longest queue is the that is exceeding its fair bandwidth share by the largest margin. Dropping packets from connections going too fast, rather than randomly, may reduce the unfairness between connections. Connections that are incapable of using their fair bandwidth share may never be targeted, while those that continually exceed it may see a much higher loss rate.
However, this QoS approach may be dependent on having a backlog of packets across a number of flows, which may be inappropriate in cases where backlog is sought to be minimized due to other concerns. These QoS mechanisms also may not apply in cases involving a single flow. Thus there exists a need for systems and methods which allow QoS to be implemented in cases where minimal or no backlog of packets exists, and with respect to single flows. These systems and methods should be applicable even in cases where parts of the network which a flow traverses are under the control of a third party.
Many network traffic uses the Transport Control Protocol (TCP) protocol, which is a connection-based layer on top of IP. TCP uses a mechanism of slowing down the sending rate when the loss of a packet is detected, and speeding up when there is no such loss. Traditional implementations (such as TCP Reno) may use a sample time of one round-trip over the network (RTT, the time between sending a packet and receiving an acknowledgement of its arrival from the receiving unit). In a round-trip in which no packets were lost, the amount of data in flight (the congestion window) may be increased by one full-sized packet. Increasing the congestion window will increase the connection bandwidth, the network queuing, the packet-loss rate, or some combination of these—depending on the state of the network. An alternative method of achieving congestion control in TCP is to use the round-trip time as the basic control signal. This is used by TCP Vegas and FAST TCP. In FAST TCP, for instance. In these implementations, the congestion window may be increased or decreased based on a comparison of a recent packet round trip time against a fastest or average round trip time.
The use of random losses to control connection speed may lead to unfairness in bandwidth allocation between connections. Given two connections, one may receive less bandwidth because it is simply unlucky, it passes over a link with an inherently higher loss rate (such as a wireless network), or it may receive less bandwidth because it has a longer path length (and hence a longer round-trip time) than its partner. Because connections speed up once per round-trip, the ramp-up rate may be steeper with short-haul connections with long-haul ones. Further, TCP may be indiscriminate with respect to connection priorities in its slowing down and ramping up of connection bandwidths in response to network events. There thus exists a need for systems and methods which can compensate for the potential unfairness of allocating bandwidth based on random losses, and which allow for QoS priorities to be factored into response to packet losses and other congestion events.